Mobile application (“app”) developers, mobility professionals and end users desire apps with seamless integration into trusted services and solutions. There are significant challenges, however, to integrating mobile apps developed using multiple programming languages on multiple platforms with enterprise grade authentication, enterprise mobility management (EMM), Access (VPN), mobile app management (MAM), security and other capabilities. Integration is time consuming and resource intensive, and multiple quality assurance (QA) and release cycles create nightmare scenarios for the mobile developer that wants to serve an enterprise customer. A mobile developer or independent software vendor (ISV) typically has to choose from three flawed integration approaches: software development kits (SDKs), mobile operating systems with app programming interfaces (APIs) and wrappers.
Software development kits (SDKs) aid the development process and are offered by every major service vendor. But SDKs still require a heavy development effort to implement, manage and maintain. Because SDKs are vendor-specific, solution-specific, and platform-specific they typically solve a tiny fraction of the overall mobile integration challenge. SDKs may make a discrete integration project easier, but the overall integration effort across multiple projects, versions, platforms and use cases remains heavy. SDKs are not automatic. They replace direct source code integration but impose an additional step in the integration process. SDKs require new expertise, one tailored to the specific SDK and still requires platform-by-platform builds, releases and QA.
Mobile operating systems have started to incorporate mobile management app programming interfaces (APIs) into their platforms. This allows mobile developers and ISVs to use the management controls inside the mobile operating system (OS) to manage devices and apps. The biggest advantage of these built in features is that the mobile developer or ISV need not compile a version of the app with a specific SDK to allow users to manage the app. The biggest disadvantage is that the OS-based feature set is not universal across platforms. One OS might support one set of features while another OS supports a different or lesser set. This divergence leaves some users and some enterprises without access to critical features needed in their environment. In many cases, the missing features force the app to fail security requirements, which hinders deployment and adoption of the app. The mobile OS approach also forces the device to be enrolled in a single EMM system. In an increasingly mobile workplace, where contracting is commonplace, this is often impractical for large-scale deployments. Mobile OSs are gaining new app management capabilities but it is early days and often not suitable for large-scale deployments where consistency and security are important.
App wrapping promise more vendor-specific faster mobile app integration than SDKs. But like SDKs, app wrappers are platform-specific, solution-specific and lack standards. Wrappers also spawn new problems such as imposing functionality limitations, often resulting in unpredictable behavior. Wrappers rely on intercepting or modifying app layer APIs. Wrappers stand between the native app functions and the EMM or MAM and can actually collide with apps. For example, when a mobile app uses frameworks or is built using mobile app development platforms (MADPs), basic EMM functions such as creating container files are a challenge for wrappers. Because wrappers are sensitive to loading order, framework usage and app logic, wrappers often cause apps and frameworks to fail. Interacting with a huge and ever-growing number of possible APIs leaves room for error. It also leaves functionally walled off by the wrapper, making wrapping undesirable for many developers. Wrapping also creates problems for commercial apps. For example, ISVs typically don't support wrapping because it interferes with the native operations of the app.